2.1 Prerequisites

This section contains information on supported Entrust versions and required software and configuration.

2.1.1 Supported Entrust versions

MyID has been tested with the following CA versions:

Note: Integration with Entrust 8.x is now deprecated. See the Entrust Certificate Authority version 8 section in the Release Notes for details.

You are recommended to monitor the published support lifecycle dates for Entrust products, including certificate authorities and integration toolkits that are listed as pre-requisites for MyID integration. Where issues are raised against these product integrations, Intercede will investigate on a reasonable endeavors basis to achieve a resolution, but ultimately may not be able to resolve problems without further support from Entrust, which may be limited if the standard or extended support dates have passed on the affected products.

2.1.2 Required software

Before using the Entrust JASTK CA to issue certificates through MyID, you must install and configure the following software components on the MyID application server:

You also need the following information and files to configure MyID to use the Entrust CA:

2.1.3 Java Environment

To enable the Java Interface between MyID and the Entrust server to function correctly, all the .JAR files must be in the same location on the MyID application server. You have the following options:

If you are using HSM-based credentials, you must also copy the following files from the Entrust Java Toolkit to the System32 folder on the application server:

2.1.3.1 Check the Path variable

You must check that the Path environment variable on the MyID application server contains both the location of the client jvm.dll file and its parent folder.

Important: If you update your version of Java, you must check the Path environment variable again, and update it if necessary.

  1. Log on to the MyID application server as an account with administrative rights.
  2. From the Windows Control panel, select System.
  3. Click Advanced system settings.
  4. Click Environment Variables.
  5. From the list of System variables, select Path.
  6. Click Edit.

  7. Check that the full path of the folder containing the client jvm.dll file is included in the Path variable.

    For example:

    C:\Program Files\Eclipse Adoptium\jdk-21.0.4.7-hotspot\bin\server

    If this folder is not present in the path, add it.

  8. Check that the path of the parent folder of the folder containing the client jvm.dll file is included in the Path variable.

    For example:

    C:\Program Files\Eclipse Adoptium\jdk-21.0.4.7-hotspot\bin

    If this folder is not present in the path, add it.

    Note: Make sure the paths are correct. If the paths are entered incorrectly, or are missing, you may experience errors, or you may experience a loss of functionality as the failure to find the jvm.dll file causes a silent failure.

    You must make sure that there are no spaces after the semicolons that delimit the entries in the path variable.

    For example:

    <Paths>;C:\Program Files\Eclipse Adoptium\jdk-21.0.4.7-hotspot\bin\server;C:\Program Files\Eclipse Adoptium\jdk-21.0.4.7-hotspot\bin;<More paths>

  9. Click OK to save any changes you have made to the path.
  10. Click OK to close Environment Variables.
  11. Click OK to close System Properties.
  12. Restart the server.

2.1.4 Issuing certificates to users who do not exist in the directory

If you want to issue certificates to users who do not exist in the directory, make sure you have set the noUserInDirectory=1 setting for the certificate policies you want to issue.

If you do not set this, and attempt to issue a certificate to a user who does not exist in the directory, Entrust displays an error with the generic code -1685.

You can find this setting in the master.certspec file on the CA. See your CA documentation for the procedure for updating this file.

2.1.5 Certificate revocation list

The MyID application server must be able to communicate with the Certificate Revocation List (CRL) location. The CRL is checked for validity whenever MyID connects to the CA. If using a Microsoft ADS-backed CA, this is not the case by default for CRLs published to the directory. Ensure that your CRL publication is to a publicly accessible location.

2.1.6 Multiple Entrust digital identities with a single Luna SA HSM

It is possible for a toolkit application to support multiple Entrust digital identities concurrently with a single Luna SA HSM.

For more information, see the Entrust note reference TN7074.

One example could be two servers, Server1 and Server2 that require separate identities on the same Luna SA. In this case two partitions can be created on the Luna SA: PartitionA and PartitionB. PartitionA can then be assigned to Server1 and PartitionB can be assigned to Server2. When Server1 contacts the Luna SA through PKCS #11, PartitionA is exposed as a single slot visible on the Luna SA. Similarly Server2 sees one slot, as PartitionB is exposed to it. Each server based application can then create and log in to separate identities hosted on different partitions on the Luna SA.

In the case of multiple partitions assigned to a single client, for example, if Server1 has both PartitionA and PartitionB assigned to it:

The clients will see multiple slots. The ckdemo tool can be used to verify how many slots are exposed.

The Java based clients would just pick the desired slot and attempt to log in to the identity on that particular slot.

Entrust Authority Security Toolkit for the Java Platform (ETJava) would take the profile name that is specified and cycle through the slots until it finds the correct identity. The profile name (.tkn entry) should be the concatenation of the "Entrust Path" and "Entrust User" data blobs from the LunaSA with ".tkn" appended. A Windows based example could be something like:

d:\\test\\admintk\\luna_officer_wf.tkn

2.1.7 Certificate content

In some circumstances, it is possible that, for a given user, the contents of certificates are controlled by the Entrust policy; attributes may appear in certificates that you are not expecting. To prevent this, make sure that any unwanted extensions are explicitly blocked in the certificate policy configuration on the CA; use the SMA UI or another Entrust tool to enforce the Subject Alternative Name content.

2.1.8 User SID extensions

To set up your certificate authority to issue certificates with a user security identifier (user SID) extension for Windows authentication, you must configure the certificate template on the Entrust CA. See your Entrust documentation for details; the Entrust SMA User Guide provides instructions on how you configure a policy on the CA to accept the objectsid, and provides an example certificate type ent_sid_keypair.

In the Certificate Authorities workflow, you can edit the attributes for the policy to set the User Security Identifier attribute to have a Dynamic mapping to User Security Identifier; see section 2.10, Enabling certificate policies.

For information on user SIDs, see the Including user security identifiers in certificates section in the Administration Guide.